An Evaluation of Regent and Legion in the Parallel Programming Landscape

Legion is a fairly new runtime system and Regent is an even newer programming model that attempt to address the difficulty of writing high performance applications on distributed architectures with minimal complexity handling data partitioning and dependencies [1]. Regent is a dynamic language based on Lua optimized for high productivity that runs on the Legion runtime. [2] Very little research has been done so far analyzing the optimal use case for Regent and Legion and comparing the same program written in Regent with one written in traditional MPI or Charm++. I was interested in how writing implicit parallel programs differed in Regent vs. competing systems and whether it was able to achieve comparable or better performance with less complexity. Legion was created in 2012 and Regent was first developed in 2015, making them far newer than the more established systems I compared them to. MPI (Message Passing Interface) has long been the canonical standard for writing parallel programs on distributed architectures. However, MPI focuses on describing parallelism alone and does not handle imbalanced loads or provide abstractions for describing data. It was created in the early 1990’s. Charm++ is an object oriented parallel computing language built on C++ and developed in the Parallel Programming Laboratory at the University of Illinois. It has been around since the late 1980’s, although has existed in something close to its current state only for the last fifteen years. Charm++ allows programmers to describe their data in terms of objects and provides automatic load rebalancing by mapping objects to processors. [3] I avoided comparing Legion with implicitly parallel languages that execute on shared memory such as CUDA or OpenMP. Writing parallel programs for distributed architectures is increasingly important as larger super computer systems are built, and the movement of data largely impacts performance on such systems. Parallel languages on shared memory do not optimize for avoiding data movement and therefore were not comparable. I also excluded Spark, which executes on clusters with distributed shared memory. Spark was left out because it is not nearly as performant as C++ based systems. [4]